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The MIT-SSL SPHERES testbed provides a facility for the development of algorithms 
necessary for the success of Distributed Satellite Systems (DSS). The initial development 
contemplated formation flight and docking control algorithms; SPHERES now supports the 
study of metrology, control, autonomy, artificial intelligence, and communications 
algorithms and their effects on DSS projects. To support this wide range of topics, the 
SPHERES design contemplated the need to support multiple researchers, as echoed from 
both the hardware and software designs. The SPHERES operational plan further facilitates 
the development of algorithms by multiple researchers, while the operational locations 
incrementally increase the ability of the tests to operate in a representative environment. In 
this paper, an overview of the SPHERES testbed is first presented. The SPHERES testbed 
serves as a model of the design philosophies that allow for the various researches being 
carried out on such a facility. The implementation of these philosophies are further 
highlighted in the three different programs that are currently scheduled for testing onboard 
the International Space Station (ISS) and three that are proposed for a re-flight mission: 
Mass Property Identification, Autonomous Rendezvous and Docking, TPF Multiple 
Spacecraft Formation Flight in the first flight and Precision Optical Pointing, Tethered 
Formation Flight and Mars Orbit Sample Retrieval for the re-flight mission. 


I. Introduction 

T HE SPHERES testbed provides a vehicle to demonstrate and validate formation flight and docking technologies 
for use in missions such as Terrestrial Planet Finder (TPF) and Orbital Express. Among the technologies that 
are actively under study by SPHERES are space interferometry, cluster reconfiguration, and mission re-supply. 
Many of these techniques can only be tested in simulation or with expensive and risky flight projects. Currently, 
there are no on-orbit resources suitable for the validation of general simulation results, and most space missions do 
not push the limits of performance due to the high risk associated with flying unproven algorithms. The SPHERES 
testbed is an inexpensive and risk-tolerant laboratory for the validation of distributed spacecraft control, estimation, 
and autonomy algorithms. It fills the gap between the flexibility, risk-tolerance, and uncertainty of simulation-based 
research and the inflexibility, expense, and credibility expected from future space flight missions. 

The SPHERES testbed was developed as part of the ongoing research initiatives of the MIT Space Systems 
Laboratory (MIT-SSL) that utilize the space environment provided by the space shuttle and International Space 
Station (ISS) to validate dynamics and control algorithms. This testbed builds on the experiences learned with the 
Middeck 0-gravity Dynamics Experiments (MODE) and Middeck Active Control Experiment (MACE) family of 
dynamics and control laboratories (STS-40, 42, 48, 62, 67, MIR, ISS). The lessons learned from these experiments 
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developed into a design philosophy for future 
MIT-SSL projects under which new facilities, 
such as SPHERES, are designed to welcome 
the participation of multiple researchers while 
at the same time maximizing the return from 
operations in a p-g environment under human 
supervision. 

The SPHERES testbed consists of two 
parts: a ground testbed located at MIT, and a 
flight testbed that will be operated by 
astronauts as an interactive laboratory 
onboard the ISS. The SPHERES testbed will 
utilize the unique properties of the ISS to 
create a laboratory environment for the 
development and validation of control, 
estimation, and autonomy algorithms. Among 
the most important aspects of the ISS 
considered by SPHERES are the supervision 
of experiments by humans, the short-return time of data for validation of results, the risk-tolerant environment inside 
the ISS, and the long duration full exposure to micro-gravity dynamics with six degrees-of-freedom (6 DOF). By 
supporting a wide range of research areas in a single testbed, SPHERES provides an effective common laboratory 
facility and avoids the extra costs of multiple single-purpose flight projects. 

SPHERES was initially developed in 1999/2000 by a group of senior undergraduate students at MIT, who built 
two prototype units. The MIT-SSL, together with Payload Systems Inc. (PSI), continued development through 2003 
and the flight units were certified for operations aboard the ISS. The flight units were originally manifested for 
flight in early 2003; the units are now expected to launch on STS 116 in mid-2005, shortly after return-to-flight of 
the space shuttle. 

A. SPHERES Overview 

The basic setup of the SPHERES testbed consists of a number of autonomous free-flyers satellites, a laptop 
computer that serves as a ground station, and small beacons that form the Position and Attitude Determination 
System (PADS). SPHERES has three main operational environments: simulation, MIT-SSL facility, and the ISS. 
The simulation allows the operation of up to three satellite models in any standard PC running Windows operating 
system. The configuration at the SSL facility consists of two operational flight-qualified SPHERES satellites, a 
metrology setup optimized for 2D operations, and a metrology setup designed for 3D operations. The final ISS 
configuration will consist of three satellites and a 3D metrology setup. Both MIT-SSL and ISS setups use a laptop 
computer to represent a ground control station; through the laptop, the user runs tests and collects telemetry data for 
future analysis. Figure 1 shows an operational concept of the SPHERES testbed onboard the ISS. 

The laptop computer utilizes a custom communications device to control the satellites and store all the data. 
Different interfaces were developed for the ISS and ground 
operations; the ground interface minimizes the time between 
tests, while the ISS operations clearly steps through the 
operation procedures to ensure correct tests are being 
implemented. The five beacons create the working area, 
described below as part of the satellite sub-systems. 

B. SPHERES Satellites 

The individual self-contained satellites (Figure 2) have 
the ability to maneuver in up to six degrees of freedom, to 
communicate with each other and with the laptop control 
station, and to identify their position with respect to each 
other and to the experiment reference frame. Physical 
properties and other specifications for the satellites are listed 
in Table 1. 

The satellites are propelled by a cold-gas thruster system 
which uses carbon dioxide as propellant. The C0 2 propellant 



Figure 2. SPHERES satellite 
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Table 1. SPHERES Satellite Properties is stored in liquid form at 860 psig; a regulator reduces the 

pressure to 35 psig. Twelve thrusters are positioned to 
provide controllability in all six degrees of freedom, enabling 
both attitude and translation control. Each thruster assembly 
consists of a solenoid-actuated micro-valve with machined 
nozzles. Depending upon the tests of interest, a single tank 
provides approximately 30 minutes of active operation. After 
each test session, a tank can be left in the system partially 
full, for use at a later time, or be replaced with a new tank. 

The PADS provides metrology information to the 
satellites in real-time. An Extended Kalman Filter uses data 
from inertial body sensors and a global frame measuring 
system to obtain the state vector in the coordinates of the 
reference frame. The global metrology system is a pseudo-GPS ranging system that uses ultrasonic time-of-flight 
measurements from the beacons placed at known locations in the testbed's reference frame to the ultrasonic 
microphones distributed on the surface of each satellite. These time-of-flight measurements are converted to ranges 
and are then used to derive position and attitude with respect to the reference frame. 

A Texas Instruments C6701 Digital Signal Processor provides the computational power. The ability of the 
C6701 to provide up to 1.0 GFLOPS provides significant processing power to prevent being the limiting factor in 
the performance of the system. A FLASH memory size of 224 KB allows software re-configuration of the full 
operating system, ensuring that multiple investigators are supported while the system is in the ISS. 

The power system utilized onboard the ISS consists of packs of AA alkaline batteries while NiMH rechargeable 
packs are used on the ground facility. The packs provide each satellite with approximately two hours of operation; 
once a pack is consumed, it can be easily replaced. 

Each SPHERES satellite uses two separate frequency communications channels operating at 57.6 kbps each. 
One channel is used for satellite-to-satellite communications; the other channel enables satellite-to-laptop 
communications. Both channels are bi-directional; however, the communication hardware is half-duplex, meaning 
that only one unit can transmit at a time. 

II. Design for Collaborative Research 

The original goal of SPHERES was to develop a testbed for formation flight and docking. These two subject 
areas constitute a part of the larger field of Distributed Satellite Systems (DSS). The MIT-SSL identified the 
following major topic areas for study within DSS: 

• Metrology - Each satellite in a DSS requires knowledge of both its attitude and position as well as that of 
the other satellites. One must investigate the need for absolute measurements (e.g. a radar pointing towards 
Earth) versus differential measurements (e.g. docking) and between coarse (e.g. radar) and precise 
measurements (e.g. interferometry). 

• Control - The control fields vary over a large range. High-level architecture determines the type of 
hierarchy in the system (e.g. leader/follower); an example of an intermediate level is fuel-balancing 
algorithms; low level control includes rigid body control of each unit. 

• Autonomy - One goal of DSS is to minimize human intervention. At a minimum, the main maneuvers of the 
system should complete autonomously; human intervention should only occur at high levels, such as 
specifying the current task. 

• Artificial Intelligence - AI goes a step beyond autonomy by providing the extra advantages of automatic 
system reconfiguration and error detection and correction, among others. AI technologies in DSS help 
further minimize human intervention in the case of a problem or a new mission goal. 

• Communications - DSS satellites require communications both to ground (high power) and between the 
units (low power). Each program must study its optimal communications configuration. 

• Human/Machine Interfaces - Given the limited interaction between humans and free-fliers in space, the 
possible uses and interfaces between satellites and humans must be studied. 

The final design of SPHERES contemplates the possibility that it could support investigation in multiple areas, 
beyond the original two subjects. Since the study of such a large field as DSS is performed by a wide range of 
researchers, the SPHERES project had to support multiple researchers. Therefore, the SPHERES team had to take 
into account several important features that must be present in a facility 1 : 


Diameter 

0.25 m 

Mass 

4.0 kg 

Max Linear Acceleration 

0.17 m/s 2 

Max Angular Acceleration 

3.5 rad/s 2 

Battery Life 

-120 min 

Communications Data Rate 

57.6kbps 

Power 

13 W 

Metrology Resolution 

1.0 cm 

2° 

Tank Life 

-30 min 
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• generic equipment, the hardware of the system must be generic enough that a wide range of researchers can 
use it to obtain results 

• hardware expandability’', the hardware must support the addition of equipment to support specific aspects of 
the research of each scientist 

• software reconfiguration', researchers must be able to write their own software for the generic equipment 
such that it behaves in a manner to support their research 

• remote operations : the project must contemplate that operations may occur remotely - that is, the main 
researcher may not be present where the hardware is operated 

A. Hardware Design 

The SPHERES satellites fulfill the need to provide generic equipment. These satellites represent a general 
spacecraft bus. The primary functions of a spacecraft bus are to support the payload, provide maintenance of orbit 
and pointing of the payload correctly, and provide power, communications, and data storage. To accomplish these 
goals, spacecraft payloads utilize the following main sub-systems: propulsion, attitude determination and control, 
communications, command and data handling, thermal, power, and structures sub-systems 2 . The SPHERES 
satellites provide each of these sub-systems, thus supporting a wide range of research within the field of DSS. 

SPHERES does provide for the expandability of the hardware components. Each SPHERES satellite has two 
flat panels on opposite sides that can be used to expand the hardware payload. One side provides a passive 
mechanical attachment point, where expansion items that do not need any connections to the satellite electronics can 
be attached. For example, this panel can be replaced by a passive “docking pin.” The other side provides both 
mechanical and electronic connection points. This side, called the SPHERES Expansion Port (pictured in Figure 3), 
interfaces to the main electronics stack via both serial and parallel lines, and provides power for external 
components. Expansion items can interface to the main processor, allowing all algorithms to reside within the main 
SPHERES software. The Expansion Port can be used for items such as an active docking mechanism with sensors 
and actuators, among many other applications. 

B. Software Design 

The hardware allows for the algorithms provided by the different researchers to all be tested using the same 
system bus, regardless of the science-specific equipment attached through the expansion port, if any. Therefore, the 
software of the satellites must allow multiple researchers to use the general bus and interface with their specific 
equipment. To this purpose, the testbed’s software design was almost entirely driven by the need to accommodate 
multiple researchers. The goal in the software design was to create an architecture that was relatively easy to learn 
and flexible enough to accommodate a wide variety of the sophisticated applications within the main areas of DSS. 
The main challenge was to balance the goals of usability and capability. The goal of ease-of-use called for a clear 
and logical model of software operation, and the automation of tedious or non-productive tasks. In contrast, the goal 
of versatile functionality suggested an emphasis on real-time performance and a flexible execution model. 

The SPHERES team created a framework for the development of software that allows researchers to concentrate 
on their specific goals, rather than on the general operations of the satellites, called the SPHERES Core. The 
SPHERES Core software layer performs two functions. First, it acts as a buffer between the user-provided 
experiment code and the operating system and hardware. Mediating between these layers, the core services control 
the execution of the user-configurable processes and encapsulate the operating system and hardware-specific 
interfaces. Second, this layer performs a number of background 
activities that are critical to successful operations. 

The interfaces with the user are: control, communications, 
propulsion, metrology, and background processes. The interfaces 
allow users to customize how the major elements of the spacecraft 
bus operate by either creating their own software of utilizing 
standard modules provided by the SPHERES team. The control 
interface supports a wide range of control frequencies as high as 
1kHz. The module also controls test initialization and 
synchronization between multiple satellites to within 1 ms. 

SPHERES core implements a wide range of standard control 
algorithms and maneuvers to interface with the propulsion system; it 
also provides multiple pulse-width-modulation implementations for 
direct access to the thrusters. The communications software 

implements a Time Division Multiple Access scheme. The user can figure 3- SPHERES Expansion Port 
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configure the frame lengths and the use of 
high and low priority queues to 
investigate the effects of communications 
in DSS. To allow a wide range of 
research on Metrology algorithms, the 
core software provides users with two 
periodic routines to sample the IMU and 
the global metrology system, as well as a 
background process that can run 
asynchronously over long periods of 
time. This allows easy implementation of 
a wide range of Kalman filters and other 
state determination algorithms. A full 
description of the SPHERES Core 
software layer can be found in Reference 
3. Figure 4 illustrates the main elements 
of SPHERES Core and the interfaces 
with the scientist and hardware. 


C. Operations 

Thus far the support of multiple 
researchers has concentrated on the 
ability of the individual satellites to be 
configured and programmed for specific 
operations. The project completes the 
support of multiple investigators with a broad range of tools and facilities that allow researchers in different 
geographical areas to take advantage of SPHERES. These tools include the design of operations for the testbed and 
the ability to operate SPHERES on a broad range of facilities. 

1. Operations Plans 

The SPHERES operations plan is based on three main levels of development: local development at the 
researcher facilities via a computer simulation, experimentation at the MIT-SSL facility, and operations onboard the 
ISS. Each of these levels increases the fidelity of the simulation while operations become more complex. 
Therefore, the SPHERES team developed a “Guest Scientist Program (GSP)” to allow researchers smooth and quick 
transitions from one environment to the next. Figure 5 illustrates the full SPHERES operational plan for tests 
beginning in the simulation phase to being ultimately operated onboard the ISS. 

The SPHERES simulation provides a means for guest researchers to independently implement, test, and modify 
algorithms for the testbed, while minimizing reliance on long-distance communication and physical access to the 
testbed hardware. The simulation is designed to facilitate efficient interaction between guest researchers and the 
MIT SPHERES team. Custom source code may be compiled and linked into the simulation environment to verify 
syntax and appropriate interaction with the existing SPHERES software. The simulation engine can be used to 
predict the behavior of the hardware in both the ground and microgravity environments. The simulation also helps 
the guest researchers learn how to use the interface to the flight software and reduces reliance on access to the 
testbed hardware. 

The SPHERES ground laboratory provides a 2D, three degree of freedom environment in which to test 
algorithms prior to deployment to the ISS. The ground testbed is located at the MIT-SSL in Cambridge, MA. The 
laboratory can be operated at low cost, allowing a large number of iterations during algorithm development. The 
hardware used in the laboratory is identical to the flight hardware. For 2D operations, the satellites are mounted on 
air-bearing carriages that allow translation in two axes and rotation about one axis. Two metrology systems are 
available; one is optimized for 2D operations on the air table, and the second serves as a copy of the configuration 
onboard the ISS. Because the hardware is identical to that on the ISS, operations are subject to realistic 
imperfections, uncertainties, and effects that are not modeled in the simulation. The facility provides feedback to 
researchers in two forms: a member of the SPHERES team may run the experiments locally, and forward the results 
to the researchers; alternatively, researchers may decide to visit the MIT-SSL for several days or weeks to conduct 
their experiments, obtaining feedback immediately. 



Figure 4. The SPHERES Core software layer 
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The ISS laboratory will provide the opportunity to 
conduct extended-duration microgravity experiments. 

Investigators may use up to three satellites in their 
experiments. The metrology system will be set up to 
provide 3D position and attitude resolution. Tests will 
be started and supervised by an astronaut using an ISS 
standard equipment laptop as a control station. Data 
transfers will occur after completion of the test session. 

Data download to the ground is to occur the night after 
each test session, and video data will be downloaded 
within a week of each experiment. The data are 
delivered by NASA to the MIT-PSI SPHERES team and 
then forwarded to the guest researchers. Test sessions 
onboard the ISS are expected to be every two weeks, 
with researchers choosing to run experiments at 
intervals of two or four weeks. 

Through its three layers, the GSP provides multiple 
researchers, with varying research interests, to perform 
tests using the SPHERES testbed. The simulation 
allows each scientist to prepare their code in-house, 
which can be done in parallel by multiple researchers. 

Support of the program at the MIT-SSL allows multiple 
researchers to schedule operational times, which is 
available throughout the year. The ISS will allow Figure 5. SPHERES Operations Overview 
multiple researchers to run tests by sharing test sessions 

and possibly intercalating their scheduled operating sessions so that each researcher has enough time to evaluate 
their data, reprogram their algorithms, and re-upload their algorithms for a new ISS test session. 

2. Operational Environments 

To meet several safety and operational requirements for operations onboard the ISS, the final system design is 
highly portable and simple to operated in a wide range of environments. This feature has provided the SPHERES 
testbed with an expanded base to demonstrate different algorithms for a wide range of missions. The benefits of this 
portability are accentuated by the long term for operations onboard the ISS. By operating in a wide range of 
environments, SPHERES has been able to conduct tests in micro-gravity conditions even without the ISS by using 
the KC-135 Reduced Gravity Airplane. While the test area within the MIT-SSL is limited to approximately 1 m 
square, operations at the Marshall Space Flight Center (MSFC) flat floor facility have allowed demonstrations of 
algorithms on an area over 3 m square. This section describes the benefits and limitations of the operational 
capabilities of the three environments; the next section describes the type of research conducted in the different 
environments. 

The MIT-SSL facility utilizes air carriages that enable frictionless motion in 2D. The carriages float over a flat 
glass approximately 1.0 m squared (4 feet squared); the metrology system covers an area approximately 2 m cubed. 
An important benefit includes the low-stress nature of the facility. This includes practically unlimited time to 
develop algorithms and the ability to replenish the consumables without any limitations, since batteries can be 
recharged and gas replenished in house. The presence of the researcher is possible to improve the feedback process. 
At the same time, this facility does present some limitations. The air carriages can only operate for up to 20 minutes 
before requiring gas replenishment, thus limiting the maximum test duration time. The 2D nature of the testbed 
makes only a partial representation of micro-gravity environment; while the three present degrees of freedom are 
relevant, the dynamics of the testbed are not easily expandable to 6 DOF. 

The KC-135 operational benefits start with the ability to perform 6 DOF tests and expand the operational volume 
to a 3m cube. These benefits present a clear improvement over the MIT-SSL in the ability of SPHERES to provide 
a representative environment of DSS systems. Tests conducted onboard the KC-135 are subject to the full dynamics 
of micro-gravity, and the results of these tests are expandable to full micro-gravity conditions. But the KC-135 
environment presents several limitations, mainly related to time constraints. The SPHERES operations in this 
platform require a very specific plan, where a set of tests are planned for each day onboard the KC-135, without the 
ability to modify (recompile) the content of the tests in real time. After each daily test sessions, both video and data 
analysis occurs, and the programs are modified in the evening for testing the next day. The limit of micro-gravity 
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time also presents a barrier to conduct tests. Each micro-gravity period is approximately 20 seconds long, requiring 
that an algorithms perform a useful maneuver within that time. While some researchers have been able to divide up 
their algorithms into 20 second increments, it is clear that such a short time limits the amount of science conducted 
onboard the KC-135. A further limitation of the KC-135 is that tests can only be performed over a one week period, 
and subsequent tests will require further funding to operate onboard the aircraft and are usually no less than six 
months apart. Ultimately, the KC-135 provides a unique environment that allows proof-of-concept tests and which 
has benefited the SPHERES program by exposing flaws in the operational aspects prior to deployment to the ISS. 

The MSFC flat floor facility provides an environment similar to that of the MIT-SSL, except with a substantially 
expanded operational area. The major benefit is the operational area expansion to over 10 meter squared (30 feet 
square). The environment is relatively free of stress. The schedule test time is usually in terms of full days, allowing 
the researchers to iterate on their algorithms after every test run. Researchers are not required to run one test after 
another. Further, the facility also allows all consumables to be replenished with ease in a virtually unlimited fashion. 
The MSFC installations do have some shortcomings. The area cannot accommodate a full metrology system to 
provide state information with a global frame of reference (e.g., the flat floor); rather, all operations at MSFC 
require relative control of the spacecraft. This shortcoming can be overcome by the large area, since the center of 
mass of the formation will always remain within the large area. While time is not a major issue, the tests are limited 
to the length of the visit to MSFC; further scheduling of the facility usually requires a few months of advance notice. 
Lastly, tests are again limited by the air carriages ability to operate friction-less; in the case of the MSFC 
installations the operational time is approximately 10 minutes, since the conditions of the flat floor are different than 
those at MIT-SSL facility. 

The ISS operational environment is yet to be tested. The expected operations will resemble an expanded version 
of the KC-135. Full 6 DOF operations will be possible. Tests will no longer be limited to 20 seconds, but rather by 
the consumable times: 30 minutes for propellant and two hours for batteries. Each test session is expected to be two 
hours long. But as with the KC-135, the ISS operations will require that a full range of tests be planned in advance, 
and that tests be run continuously over the two hour sessions. Researchers will get the opportunity to analyze data 
and modify their algorithms in between test sessions, not between tests. Further, test sessions will be scheduled at 
lest two weeks apart, therefore researchers must ensure that any modifications be substantial enough to make each 
tests session worthy. However, the fidelity of the tests aboard the ISS overcomes the shortcomings of the 
environment. 

Ta ble 2. SPHERES Operational Environments 



Fidelity 

DOF 

Test Time 

Algorithm 
Dev. Time 

Environment 

Challenges 

Simulation 

Low 

6 

Unlimited 

Unlimited 

Low 

SSL 

Medium 

3 

20 min 

Unlimited 

Low 

MSFC 

Medium 

3 

10 min 

24-72 hours 

Medium 

KC-135 

High 

6 

20 sec 

24-72 hours 

High 

ISS 

Very High 

6 

30 min 

2 weeks 

Medium 


III. Research with SPHERES 

Through its GSP, spacecraft dynamics and control researchers with very different research interest can develop 
and test their algorithms on the SPHERES testbed. The MIT-SSL is supporting three programs for experiments on 
the SPHERES testbed onboard the ISS. These programs include one-satellite experiment for Mass Property 
Identification, two-satellite experiment for Autonomous Rendezvous and Docking (ARD) and up to three satellites 
to support the TPF mission. While these programs are currently running, three more programs have been proposed 
for a future re-flight mission. Rather than developing an entirely new set of hardware, these three programs have the 
option of launching specific payload to complement the original SPHERES testbed, thus reducing the overall 
development and cost to each of these programs. 

A. Current Programs 

In this section, overviews of the three programs that are running at the MIT-SSL are presented. These three 
programs include supporting the guest researchers from NASA Ames to implement their Mass Property 
Identification algorithms onboard the SPHERES testbed, algorithm development for Autonomous Spacecraft 
Rendezvous and Docking funded by DARPA and spacecraft formation flight work in support of the Terrestrial 
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Planet Finder mission. Algorithms from these programs are 
to be tested during the first SPHERES flight onboard the ISS. 

1. Mass Property Identification 

The idea of using a characterized model of a system 
to augment the controller becomes much more powerful if 
one can perform on-line real-time characterizations. This 
allows system parameters that are changing, such as center of 
mass and moment of inertia due to fuel depletion or docking 
of two spacecraft, to be tracked, thus allowing for better 
controller performance with these updated models. The 
identification of these parameters using only gyroscope 
measurements is proposed in Reference 4. Through funding 
from NASA Ames, the MIT-SSL is tasked to help 
Intellization (subcontractor of NASA Ames) to implement 
the proposed algorithm from Reference 4 on the SPHERES 
testbed. 

Even though related, the determination of the satellite’s center of mass and moment of inertia are somewhat 
different problems. The center of mass can best be estimated from commanded pure translational maneuvers. 
Through rigorous thruster strength characterization done apriori to the experiment, any net rotation observed by the 
gyroscopes as a result of such maneuver will allow determination of the center of mass for the satellite. On the other 
hand, the moment of inertia estimate can best be obtained when the satellite are commanded to follow pure rotation 
maneuvers. In this case, the angular acceleration of the satellite is estimated from the gyroscope data and through 
Euler’s dynamical equation, the inertia is determined. Note that the determination of these parameters will require 
some knowledge of each other, thus making this an iterative problem. 

Thus far, the online mass property identification algorithm has been implemented and tested at MIT-SSL facility 
and also aboard the KC-135. Figure 6 shows the z-axis inertia estimate of satellite when it is attached to the air- 
carriage during a test session performed at the MIT-SSL. The two red curves bounding the middle curve represents 
the 1 -ct variation of the inertia estimate. 

The first set of algorithms for testing onboard the ISS for the first SPHERES flight has been successfully 
implemented on the testbed. Future improvements to the algorithms include updated filter coefficients for 
determining angular acceleration, using accelerometer data to improve the identification, or combining it with other 
autonomy algorithms such as thruster Fault Detection Identification and Recovery (FDIR). 

2. Autonomous Rendezvous and Docking 

ARD can enable new solutions for space systems designers like space interferometers and satellite servicing. 
Recognizing this, the Defence Advanced Research Program Agency (DARPA) is currently funding the development 
of an on-orbit space docking demonstration by 2006 under the Orbital Express program 6 . In the mean, DARPA is 
also funding the development of SPHERES to develop and test ARD algorithms prior to demonstration in 2006. 

The ultimate goal of the SPHERES ARD program is to develop a control architecture consisting of various 
algorithms that will enable safe and fuel efficient docking of a thruster based spacecraft with a free tumbling target 
in presence of obstacles and contingencies. The approach is to use the SPHERES testbed to test the algorithms and 
bring them up to a confidence level where they can reliably be used in space programs. 

Three classes of algorithms have been developed: metrology, control and autonomy. At the lowest class, 
metrology class algorithms were implemented through a standard interface developed by the SPHERES team 3 . The 
algorithm governing PADS is included in this class. It consists of a series of extended Kalman filters that derive the 
state vector from the sensor outputs that would correspond to any sensor suite that can be envisioned: global 
positioning only; Internal Measurement Units (IMU) only; and global positioning with integrated IMU 7 . The next 
class above the metrology class is the control class algorithms, which include path planning as well as close-loop 
control algorithms. Currently, a glideslope planning algorithm has been implemented on the SPHERES testbed to 
plan for the docking approach. The planning algorithm commands the incoming velocity to decrease linearly as 
distance between the two spacecraft closes 8 . A series of PD controllers coupled with a pulse-width modulator, 
control the attitude and the lateral alignment during the approach 9 . At the highest class, autonomy algorithms are 
used to determine the mode of operation (type of docking and phase of the approach), as well as executing the plan 
generated by the control class algorithms. FDIR algorithms also fit into this class and they are also being 
implemented on the SPHERES testbed 10 . 
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Different docking scenarios were developed to account for the different levels of cooperation between the 
chasing and the target satellite. Demonstrations were performed on the SPHERES testbed, where one Sphere 
assumed the role of the chaser and the other, the target. Results from a docking maneuver performed with a fully 
cooperative target are shown in Figure 7. In this scenario, both satellites are originally pointed in some random 
directions and have access to both the full SPHERES PADS metrology estimate and relative measurements between 
the satellites. 

Plots in the top row represent the absolute positions of the satellites as functions of time; while the second 
represents the satellites’ velocities; followed by the quaternion and the angular rates for both the satellites. Clear 
marked on these plots are four distinct phases of the experiment: (1) navigation filter initialization phase; (2) 
orientation of the chasing satellite’s docking port to the target, followed by (3) orientation of the target satellite’s 
docking port to the chaser; and (4) the approach phase where the chasing satellite closes in to dock with the target, 
which occurred at t = 92 s. 

Testing onboard the ISS is currently calls for docking of a satellite with a beacon, followed by docking with a 
cooperative satellite and finally, with an uncooperative satellite. The progression of these tests is aligned with the 
increasing complexity presented by these tests, thereby requiring more advance algorithms to be implemented. 
Future work in this program focuses on the integration of optimal path planning algorithms that account for 
constraints such as obstacle avoidance and plume impingement using techniques such as Model Predictive Control 
and parametric programming 3 * * * * * * * 1 1 . Integration of FDIR algorithms will also be of interest. 

3. Terrestrial Planet Finder Multiple Spacecraft Maneuvers 

The long baseline separations between apertures provided by a Separated Spacecraft Interferometer (SSI) system 

have led NASA to consider such a system for the TPF Mission 12 . Even though the interferometer will be operated in 

a nulling mode, the concept remains the same, the larger the separation between the apertures, the further an extra- 

solar system one can survey. Other benefits to using such a system include array reconfigurability and 

upgradability 13 . 

The coordination between spacecraft in a separated spacecraft interferometer is crucial to the success of such a 

system. To this end, the MIT-SSL, under the sponsorship of NASA JPL, has developed and tested algorithms for 

several key TPF maneuvers on the KC-135 and also on MSFC flat floor facility. These key TPF maneuvers include: 

lost in space where the spacecraft in the array are to determine their orientations with respect to each immediately 

after deployment; array spin-up where the array is spun up to the desired rotation rate; array rotation where 
continuous control actuation will be required to maintain the separations between the spacecraft; array re-sizing 
where the array size is tuned to survey the different extra-solar systems; and the most complicated maneuver, array 
re-target where the line-of-sight of the array is changed on the fly to allow for different systems to be surveyed 
without having to stop the entire array. To date, the MIT-SSL has demonstrated a limited version of the lost-in- 
space maneuver on the KC-135 airplane, followed by array spin-up, array rotation and array re-sizing maneuvers 
demonstration using three SPHERES satellites on the MSFC flat floor facility. The array re-target maneuver has 
yet to be tested due to the limited zero-gravity period that is currently available but this maneuver is expected to be 
demonstrated onboard the ISS. 
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The next step in the program is to perform the same rotation maneuver for a 5 spacecraft system on a 2-D 
facility. Once successful, the goal will then be to add an optical pointing payload and develop multi-staged control 
algorithms that are required for such a system. The development of this payload is described in next section. End-to- 
end testing of these algorithms will also be performed onboard the ISS during the first SPHERES flight. 

B. Future Programs 

Programs that are identified with the first SPHERES flight to the ISS do not require additional hardware or 
payload development, thus allowing the algorithms to be tested immediately after launch. Through the SPHERES 
expansion port, the testing capabilities of the SPHERES testbed can be further expanded. In most cases, only 
incremental payload development work is needed since the core testbed (satellites and beacons) remain onboard the 
ISS. In this section, the three programs that have been identified for potential testing onboard the ISS are presented. 
The first is the addition of a precision pointing payload to compliment the TPF maneuvers experiment. This is 
followed by a discussion on using the SPHERES testbed to study the dynamics and control of a tethered spacecraft 
interferometer system and finally, the use of the testbed as a vehicle to test the Mars Orbit Sample Retrieval 
mechanism. 

1. TPF- Multi-staged control 

The TPF maneuvers work described in the previous section provides only the coarse actuation of a SSI system. 
To realize an interferometer system, one must be able to (1) direct the light from the collector to the combiner 
spacecraft and (2) combine the same wavefront at the combiner for the various light beams reflected off the collector 
spacecraft. This finer level of control is usually provided by fast steering mirrors (FSMs) and optical delay lines. As 
the follow-on work to the TPF maneuvers demonstration, NASA JPL has funded the MIT-SSL to develop an optical 
pointing payload, which would be serviced through the SPHERES satellites’ expansion port, to facilitate the 
development of a multi-staged control testbed onboard the ISS. 

Figure shows the layout of the precision pointing experiment as setup on an optics table in the MIT-SSL. The 
setup consists of a laser source pointed at a piezo-electric FSM, which in turn direct the laser beam to a beam- 
splitter. The beam-splitter then reflects some portion of the beam to a retro-reflector, which would then be reflected 
back to the beam-splitter. This time, however, it is the transmitted beam that will be detected by the camera. Using 
the camera as a sensor, the beam can be directed using the FSM. With this setup, fundamental optical pointing 
control algorithms can be developed prior to implementation onboard SPHERES satellites. 

The next phase of the program is to package the setup shown in Figure 8 for attachment onto the satellites’ 
expansion ports. With each SPHERES satellite equipped with this optical pointing payload, multi-staged control 
algorithms can then be developed and tested. The ultimate goal will be to perform the TPF maneuvers through 
thruster actuations while maintaining precision pointing between the satellites onboard the ISS. Note that only the 
incremental optical pointing payload will need to be launched to the ISS to complement the core testbed. 

2. SPHERES Tether formation flight 

Another formation flight concept that has been considered for a SSI system is the use of tether. To image a 

target, measurements must be made in all directions 

orthogonal to the line-of-sight of the array. The balance 

between using a structurally connected interferometer, 

which allows for very limited baseline changes, and a 
SSI system where the usage of propellant can be 

prohibitively expensive, seems to be using a tethered 

system. Such a system is currently being considered for 

NASA’s Submillimeter Probe of the Evolution of 

Cosmic Structure (SPECS) mission. 

The SPECS mission attempts to address fundmental 

questions about our universe (eg. How did galaxies 
form and evolve) 2 * * * * * * * * * * * 14 . One mission concept is to use a 
Tethered Spacecraft Interferometer (TSI) system to 
maneuver the sub-apertures out to separations of a 
kilometer, thereby achieving very high resolution. 

Since power, maneuvering loads and data can be 
supported by the tether, these typical spacecraft 
functions are not required on the maneuvering vehicles. 



Figure 8 Preliminary Spheres Precision Pointing 
Experiment. 
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This reduces replication of sub-systems across the 
various sub-apertures and eliminates the need for 
propellant. Furthermore, the mass per unit length of the 
tether is much smaller than that of a deployed truss 
making it much more mass-efficient, particularly for 
long baselines. However, all of these benefits are lost if 
the control needed to achieve the precision required by 
the array proves to be too complex. It is expected that 
vibratory motion, consisting of pendulum and violin 
modes, will be observed during operations of a TSI. 
Highly maneuverable spacecraft are particularly 
problematic since beam control in the optics system 
will need to be maintained to the requisite precision 
while thrusters fire, tethers vibrate, and reaction 
wheels, or CMGs, change momentum. These introduce 
harsh disturbances that necessitate the coupling of 
attitude and optical control. 

Under the guidance of NASA Goddard Spaceflight 
Center and funding through the Small Business 
Innovation Research (SBIR) program, PSI together 
with MIT-SSL, has studied the feasibility of 
augmenting the SPHERES testbed with a tether 
mechanism to facilitate the development of dynamics and control work required for a tethered system. The tether 
package can be divided into three major components: the tether deployment and retraction mechanism with tether 
tension sensors; latch plate; and momentum wheel package. The reel in/out mechanism is used to control the tethers 
during extension and contraction. It allows the tether to smoothly and orderly maintain a tension between satellites. 
The tether from the deployment mechanism is connected to the latch plate on the other satellite, as shown in Figure 
9. The momentum wheel package, which consists of 3 wheels, is located on the opposite side of the tether 
mechanism to counter-balance the weight introduced by the tether mechanism. Note that both the tether deployment 
mechanism and momentum wheel assembly are controlled through the satellite’s expansion port and are designed to 
be modular where one design fits all three satellites. 

Based on the favorable study resulted from the Phase I work, a proposal to realize the SPHERES-Tether 
experiment has been submitted for consideration under the SBIR Phase II program. The completion of this work will 
result in a flight rated tether mechanism ready for integration onboard the Shuttle or ISS. With this hardware, 
dynamics and control work can then be studied and demonstrated on a 2-D flat floor facility prior to testing in a 
more realistic 3-D environment, onboard the ISS. 

3. Mars Orbit Sample Retrieval 

Mars has proven itself to be a highly attractive and yet daunting target for exploration due to its distance from Earth 
and its inhospitable environment. One of the cornerstones of NASA’s long-range program of planetary exploration 
is to obtain and analyze in fine detail a scientifically rich 
sample of Mars rock, regolith, and atmosphere. To 
accomplish this objective, the sample must be lofted 
from the Martian surface and returned to Earth. 

One of the greatest challenges associated with the 
Mars orbit rendezvous is the need for autonomous 
search, acquisition, rendezvous, and docking of the 
sample return spacecraft with the Orbit Sample (OS). 

This is necessary because the communication time delay 
and infrequency of good communication links between 
Earth and Mars preclude a human-in-the-loop approach. 

Some aspects of the automated OS retrieval operation 
can be adequately analyzed via computer or simulated 
via ground-based assets such as flat-floor systems. 

However, certain aspects, such as term in a I -phase multi- 
body trajectories and physical contact dynamics between 



Figure 10 Artist's concept of SPHERES MOSR 
testbed operating in ISS. 
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the OS and retrieval system can only be represented with high fidelity in a 6 DOF physical environment. 

Under the guidance of JPL through the SBIR program, PSI is currently developing a testbed to test the capture 
mechanism of the Mars Orbit Sample Retrieval system onboard the ISS (Figure 10). This testbed is separated into 
two major components: (1) capture mechanism and (2) orbit sample. The capture mechanism is essentially a cone in 
which the OS will stay within after capture. Force and torque sensors will be placed on the base plate of the capture 
mechanism to measure the impact of the OS on the cone as the velocity and rotation speed of the OS is varied. The 
OS in this experiment is represented by a SPF1ERES satellite. Since the satellite has the dimensions and mass 
properties similar to those expected for the OS, full scale emulation of an OS by the satellite can be made, thus 
allowing testing of the full scale capture mechanism. The MIT-SSL role in this effort is developing the control 
algorithms to generate the different OS velocities and spin-rates toward the capture cone. Data from this on-orbit 
demonstration will be used to verify models developed by researchers from JPL, which will then be used to build the 
capture cone mechanism. 

The current program schedule has the development of the SPHERES-MOSR flight hardware ready to enter the 
Shuttle/ISS payload integration process by early 2006. Since the integration process is expected to take between 1 to 
2 years, it is very likely that the testbed will be operated onboard the ISS by 2008. This timeline is in outstanding 
mesh in with current Mars Exploration Program objectives and the focused technology program start for a Mars 
Sample Return mission in the 2013 timeframe. 

IV. Conclusion 

The design of SPHERES welcomes participation of multiple investigators. The individual satellites support 
researchers by providing a generic satellite bus and a high-level software interface to speed up the development of 
algorithms by researchers in various geographical locations. The SPHERES operational plan and its Guest Scientist 
Program create a structured method to incrementally increase the fidelity of the tests towards a true 6 DOF 
environment. The simulation provides a simple to use interface for initial development; the MIT-SSL facilities 
challenge researchers with realistic operational and physical problems, while growing on the software developed for 
the simulation. The ISS environment will provide a realistic 6 DOF micro-gravity environment that does not 
substantially increase the complexity of the work beyond that performed for operations in ground-based facilities. 
Further, the portability of SPHERES provides the option to transport it to other ground-based facilities that can 
provide other advantages that the MIT-SSL facility cannot. This portability has allowed substantial tests to be 
performed even prior to deployment aboard the ISS. 

All these design philosophies are further highlighted in the programs that are currently being supported by the 
MIT-SSL and PSI. Beginning with a single satellite experiment performed in the MIT-SSL facility to NASA’s KC- 
135, it is now awaiting testing onboard the ISS. Similarly, Autonomous Rendezvous and Docking, and Spacecraft 
Formation Flight algorithms have been developed and tested on both MIT-SSL and the much larger MSFC flat floor 
facility, and are ready for testing in the full 6 DOF onboard the ISS. Three follow-on programs have also been 
proposed for experiments onboard the SPHERES testbed on the ISS. Since the same satellites are to be used, these 
programs only require specific payload development to complement the core SPHERES testbed. From the variety of 
programs that the SPHERES program is currently supporting, it is clear that the SPHERES testbed was developed 
with the laboratory design philosophies to accommodate multiple researchers, thereby making it a cost effective and 
yet a realistic dynamics and control testbed. 
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